In object oriented software, applications are characterized by one or more software objects and run in a process on a computer system. A software object, referred to as an object, is an instance of a software class represented as an encapsulated software component comprising data attributes and functionality. A process is comprised of one or more execution units within a computer system, with an execution unit being a single stream of executable instructions executed sequentially by a central processing unit (CPU) of the computer system. The functionality within a software class is defined by software methods which are executed at run-time. Software classes are developed to represent abstract components of an object oriented software application. Instances of software classes are created during application run-time as objects in an application. An example of an object oriented programming language and execution environment is Java 2 Standard Edition (J2SE) (a trademark of Sun Microsystems, Inc.), and an example of an execution unit which runs in a process is a Java thread and is well known in the art.
In order to create a new object as an instance of a class, an application needs to obtain a definition of the class. Class definitions are typically stored within a data store in a computer system such as a hard disk drive. The application loads the class definition from the data store using a software routine called a classloader. Each software application has at least one classloader, and different software applications may have different classloaders. The class, once loaded, is also used to access instances of the class originating outside the application, such as objects passed from other applications as parameter objects. The class is uniquely referenced by the application using a combination of a name of the class and a reference to a classloader which loaded the class. Only a class with the correct unique reference can be used by the application to access a software object instance of that class. A software object is accessible to an application if the application can access data attributes of the software object and invoke software methods of the object. In Java, for example, if a first Java application sends a parameter object to a second Java application, and the Java applications use different classloaders, the parameter object cannot be accessed by the second Java application.
The Common Object Request Broker Architecture (CORBA) (a registered trademark of the Object Management Group, Inc) is a specification defined by the Object Management Group (OMG) (OMG is a trademark of the Object Management Group, Inc.) for the interoperation of objects in object oriented applications. Using a CORBA implementation software methods of a caller object can invoke software methods of a called object. As part of this method invocation call, the caller object can send one or more objects as parameters to the called object. A parameter object is an object sent between software methods, for example an argument for a software method, a return value from a software method or an indication of a state sent by a software method (known as an exception) all of which are well known in the art. The caller and called objects can exist in different configurations within a computer system or in a network of computer systems. In one configuration, the caller object exists in an application running within a process on a local computer system and the called object exists in a second application running within a process on a different, remote computer system. This configuration shall hereinafter be referred to as a remote configuration. In an alternative configuration, the caller and called objects exist in separate applications running within a single process on the same local computer system. This alternative configuration shall hereinafter be referred to as a local configuration. Many further configurations are conceivable, each with a different organization of the caller and called objects in a computer system or in a network of computer systems.
The CORBA specification requires that an invocation of a software method in a called object by a software method in a caller object can take place regardless of the configuration of the caller and called objects. The CORBA specification further requires that the effect of a software method invocation for a specific configuration of a caller and a called object is the same as the effect of the same software method invocation in any other configuration of the caller and called objects (known as semantic equivalence). An implementation of the CORBA specification therefore allows software objects to inter-operate across heterogeneous computer systems in the same way regardless of the configuration.
FIG. 1A is a schematic diagram illustrating a prior art arrangement of two computer systems each running a process. A description of a first technique for invoking a software method in a called object using a CORBA implementation where a caller and the called objects exist in a remote configuration is provided below with reference to FIG. 1A. Caller computer system 10 includes a central processing unit (CPU) 11, a data store 12 and a process 14. Data store 12 is a non-volatile data storage medium such as a hard disk drive. An object oriented class 120 is stored in binary format in data store 12. Class 120 is used to create software objects as instances of class 120 in an object oriented application 140. A process 14 executes in caller computer system 10. For example, process 14 is a Java Virtual Machine (JVM) and class 120 is a Java class.
Process 14 includes an application 140 in binary form. Application 140 is an object oriented application and includes a classloader 1402, a caller object 1404 and a stub 1406. Classloader 1402 is a software routine executable by the CPU 11. In use, classloader 1402 loads a software class from data store 12 when application 140 creates a new software object. For example, classloader 1402 is a Java classloader. Caller object 1404 is a software object and includes object 14042 as an attribute and executable software method 14044. Object 14042 is an instance of a class loaded by classloader 1402. Stub 1406 is a software object comprising an executable software method 14062. For example, application 140 is a Java application.
Process 14 further includes an object request broker (ORB) 142. ORB 142 is an implementation of the CORBA specification and is comprised of software routines executable by the CPU 11, including routines to serialize and deserialize a software object and invoke a software method. Serializing a software object involves converting the software object into a serial stream of bytes such that it can be transmitted over a computer network or stored on a data storage medium. Deserializing a software object involves converting a serial stream of bytes into a software object within a computer system such that it can be used by an object oriented application.
Called computer system 15 includes a CPU 16, a data store 17 and a process 18 which are identical to those elements described with respect to the caller computer system 10. Process 18 includes an application 180 in binary form. Application 180 is an object oriented application and includes a classloader 1802 and a called object 1804. Classloader 1802 is a software routine executable by the CPU 16. In use, classloader 1802 loads a software class from data store 17 when application 180 creates a new software object. For example, classloader 1802 is a Java classloader. Called object 1804 is a software object and includes an executable software method 18044. For example, application 180 is a Java application. Called computer system 15 further includes an ORB 182 which is identical to the ORB 142 of caller computer system 10.
Caller computer system 10 is connected to called computer system 15 by a computer network 19 using a network protocol. For example, computer network 19 is the internet and the network protocol is the Transmission Control Protocol Internet Protocol (TCP/IP). Stub 1406 of application 140 is a CORBA stub for called object 1804 of application 180, and software method 14062 of stub 1406 is an entry point to software method 18044 from within application 140.
A method to invoke the software method 18044 on the called computer system 15 by software method 14044 on the caller computer system 10 will now be described. Software method 14044 invokes software method 14062 of the stub 1406. Object 14042 is sent as a parameter of the software method invocation and is an instance of class 120 loaded by classloader 1402. Software method 14062 passes parameter object 14042 to ORB 142. ORB 142 subsequently serializes parameter object 14042 and invokes software method 18044 of the called computer system 15 sending parameter object 14042 in serialized form over computer network 19. ORB 182 deserializes parameter object 14042 by creating parameter object 14042 as an instance of class 170 on called computer system 15 using classloader 1802 to load class 170 from data store 17. A copy of parameter object 14042 is therefore created in the called application 180. ORB 182 subsequently invokes software method 18044 sending the copy of parameter object 14042.
The first technique described above may also be used in a local configuration where the caller and called objects 1404 and 1804 exist in different applications running in the same process on a single computer system. In this configuration a single ORB in the computer system sends the method invocation and parameter object 14042 to itself over the computer network 19, because a single computer system is both the caller and called computer system in a local configuration. Computer network 19 and the associated network protocol may provide an optimization to remove the need for the method invocation and parameter object 14042 to be sent over the computer network 19. For example, in the TCP/IP protocol, a loopback feature is employed to provide a simple network connection within a single computer system where data never leaves the computer system, and is well known in the art. This provides the required network services including sending and receiving network messages and data within a single local computer system. However, where both the caller and called objects 1404 and 1804 exist on the same computer system the use of a computer network 19 to communicate between then is an unnecessary overhead, as a computer network is not required to send data between the objects.
FIG. 1B is a schematic diagram illustrating a prior art arrangement of a computer system running a process. A description of a technique for invoking a software method in a called object using a CORBA implementation where a caller and the called objects exist in a local configuration is provided below. This technique is known in the art (see “Java to IDL Language Mapping” from the Object Management Group (OMG) available on the web at cgi.omg.org/cgi-bin/doc?ptc/02-06-08.pdf, and “How does the Borland AppServer, Specifically the EJB Container, load classes?” from the Borland Software Corporation available on the Web at info.borland.com/devsupport/Appserver/faq/45/ejb/ejbconta iner-load-classes.html). All of the elements of computer system 10 of FIG. 1B are identical to those described with respect to FIG. 1A but in a local configuration. A description of the elements of FIG. 1B will not be repeated here.
Referring to FIG. 1B, a method to invoke the software method 18044 by software method 14044 will now be described. Software method 14044 invokes software method 14062 of the stub 1406. Object 14042 is sent as a parameter of the software method invocation and is an instance of class 120 loaded by classloader 1402. Stub method 14062 queries ORB 142 to determine if the called object 1804 is in the same process as the caller object 1404. If ORB 142 indicates that the caller and called objects 1404 and 1804 are in the same process, the stub software method 14062 creates a copy of parameter object 14042 by creating a new instance of class 120 using classloader 1402 with the same attributes as parameter object 14042. Subsequently software method 14062 directly invokes software method 18044, sending the copy of object 14042 as a parameter. This direct invocation without the use of a computer network is possible because both the caller object 1404 and the called object 1804 exist in the same process. Software method 18044 executes in the CPU 11.
Applications 140 and 180 have different classloaders 1402 and 1802 respectively, therefore objects created by application 140 are inaccessible to application 180, creating a significant limitation on application developers.